“Debuggers” are software diagnostic tools that provide users with mechanisms for viewing and controlling the execution of programs (including the program states and the values of variables) for the purpose of helping the user identify errors in the program code. Most software programs are written today in so-called third generation “high-level” languages which a compiler translates to machine instructions. Programs written in third generation languages are organized into functions (also referred to as procedures or routines). Functions are defined to perform specific processing tasks. They are composed of one or more lines of source code and may have their own local variables that maintain state information that is unique to the function. Functions may call other functions to perform specific tasks. When this occurs, execution transfers to the “called” function and will return to the “calling” function when the called function has completed the requested task. The execution state of the program is maintained on a “call stack,” located within computer memory, which records the current execution location in each function that has been called. When a function is called, the current execution location in the calling function is recorded in the stack. When the called function completes, this location is removed from the stack and execution resumes at the saved location in the calling function.
Conventional debuggers display a list of active functions and stack data associated with each active function (e.g., values of attributes and local variables) to allow the user to identify errors in the program code. However, due to the manner in which this information is presented, the user cannot efficiently utilize it during the debugging process. Typically, the list of active functions is displayed in a top-down or a bottom-up fashion in a separate call stack window positioned on top of a source code window. FIG. 1 illustrates an exemplary call stack display, according to a prior art embodiment.
Referring to FIG. 1, a list of active functions associated with a line 104 of the program code is displayed in a call stack window 102 presented on top of a source code window 106. As shown in FIG. 1, functions are presented in call stack window 102 in a top-down fashion in which the program's top-most function (main) is at the very top and subsequent child functions (B, I, M, I and J) are indented to the right and spaced lower in window 102. When the user needs to see the values of attributes and local variables associated with a particular function, the user can request this data by double-clicking on the area corresponding to the function. In response, a new window containing the requested data will be displayed on the screen, occupying a portion of window 102 and/or a portion of window 100. Typically, during debugging, the user needs to view the call stack data of multiple functions. Often, the user also needs to compare data associated with different functions. Each time the user wishes to request the data of a new function, the user has to return to window 102 and double-click on the area corresponding to the desired function, causing one or more windows to pop up on top of the existing windows. Multiple windows generated during debugging distract the user's attention, slow down the debugging process, and make the comparison of data associated with different functions inconvenient to the user.